NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/sys/amiga/programmer/5681

Internet Message Format | 1996-08-05 | 5.3 KB

Path: news.NetVision.net.il!news
From: Jack <[e-mail]>
Newsgroups: comp.sys.amiga.programmer
Subject: Re: 680X0 -> PPC translator?
Date: Fri, 15 Mar 1996 08:49:18 -0800
Organization: NetVision LTD.
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
NNTP-Posting-Host: ts011p8.pop4a.netvision.net.il
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 2.0b6a (Win16; I)

Volker Barthelmann wrote:
>
> In article <[e-mail]> you wrote:
> :
> : Well, even so it still doesn't affect the translation process and that's simply becuase in
> : order to make a dynamic call (ie run-time address calc.) the base address of the function is
> : referenced somewhere in the program right?!
>
> It doesn't have to be.

oh is that so?! unless you get the address from an outside source, such as allocating it YOU
must produce it, right?! so you have to have it stored somewhere in the program. if you get it
from some outside source, such as malloc(), then you don't have it obviously but that being said
doesn't imply it's impossible to figure out in which context the address is being used (ie code
or data) and make the proper modifications to the code. also bear in mind that all system
functions return pointers in either a0 or a1 and then that pointer is saved somewhere in memory
for later use, if the usage involves executing code in that part of memory then it's easy to
trace the call to malloc() or what ever else and change the required size according to the
calculated code size, remember that the code is sitting somewhere inside your executable and
therefore its size is known, comparing this value to the values pushed to the stack before the
malloc() call and you would find the exact word address to change. though it sounds complex,
nothing in life is really that simple.


>
> : so you can collect all these addresses and then see
> : where they're used as jump/call operands in an indirect call somewhere else in the program.
>
> Easy said, but really doing this is a different story. First, You'll have to
> kind of disassemble the program and therefore You have to know what is data
> and what is code, but that's what You want to decide, so...
>
> Also doing this kind of analysis is pretty much impossible on Assembler code.
> your mind is too cluttered with the complexity of things, but saying it isn't possible is simply
an unfounded claim. true things aren't that simple as with dynamic translation, but with a
little more effort they can be done, quite reliably too. and besides who says that dynamic
approach won't have the same difficulties as the static one, i can see the problem of
self-modifying code as not so easy to solve even in dynamic translation. that's because, as you
said what happens if the destination address was dynamically allocated, then you would have to
change its size again, wouldn't you?!

> : remember that all such addresses are 'lea'ed somewhere in the program and probably stored in
> : some variable in memory and when needed is used to load an address register for making the jump
>
> And a variable in memory in assembler looks like xyz(a7), but only at one
> point, because at another point it is xyz+c(a7). It is probably impossible
> to detect if they point to the same address.

so what??? if you follow the changes made to a7, assuming an initial value of 0, you would
always know what address you're refering to right, doesn't matter how you try to disguise it,
and if you're keeping track of what is being done with that address location you can figure out
what the hell it is, either code or data. you havn't obviously been listening to what i've said,
the translator isn't by any measure a stupid one, it must 'understand' the code it's translating
and make the proper modification to make it work. of course there will be exceptions to its
capablity cuz some assumptions are taken for granted, such as register usage etc, but for most
ansi-compliant programs, it will damn right be a very good tool and most compilers i know are
ansi-compliant.
>
> : or simply used directly, in either case to resolve the problem of dynamic address resolution,
> : address context analysis must be performed on EACH such address in the program, while it
> : implies hugh data structures, it is very much theoratically possible. also bear in mind that
>
> It is not theoretically possible. There are some simple cases where it may
> work, that's all.
>
> : all external references are assumed to be translated code already, so we don't care about that
> : but ALL internal references can be resolved because SOMEWHERE, SOMEONE must have used them and
> : don't tell me that function addresses are being used in arithmatic calculations, that is simply
> : weird programming, don't you agree and so the exact entry point is located somewhere in the
>
> I don't agree.
> Function addresses are often used in arithmetic calculations. Examples are
> copying of code or control-structures like in special switch-statements.
> are you sure you're talking about functions and not just jump addresses, while similar they're
NOT the same thing. i'm talking about complete functions and their entry point is fixed and
therefore can't be calculated.

-

Avi Lev.